%!TEX root = tesis-header.tex
\section{Disciplinas Relacionadas}

Crear un videojuego partiendo de librerías de desarrollo separadas requiere de un análisis basado en ingeniería de programación y algunas técnicas de programación de bajo nivel, esto debido a que no existe una metodología general para el desarrollo de videojuegos por la complejidad y variedad de este tipo de software.

A continuación se presentan las disciplinas del cómputo a las que se recurrió para el diseño y desarrollo de este proyecto. Cada uno de estos apartados podría ser examinado más profundamente, sin embargo, las herramientas que se utilizaron permiten simplificar el uso de estas disciplinas y explotar al máximo sus ventajas para obtener resultados en un menor tiempo.

\subsection{Programación Orientada a Objetos}

La programación orientada a objetos permite abstraer los objetos de entidades del mundo real con acciones y atributos. La interacción de los objetos, dentro de algoritmos especiales, es lo que conforma una aplicación que toma ventaja de este paradigma. Finalmente se ofrece una visión más modular y portable, además de una facilidad inherente de reuso de código, que solo era posible en la programación estructurada a través de funciones que no siempre podían ser usadas en otros programas con requerimientos particulares.

Sin duda la metodología orientada a objetos es vital en el desarrollo de este proyecto, puesto que la mayoría de las librerías empleadas se basan en esta filosofía. La programación orientado a objetos es solamente uno de los paradigmas que han surgido para reemplazar el uso de la programación estructurada (otros son el uso de módulos o el uso de lógica, como son \emph{Modula} y \emph{Lisp}). De la misma manera en que la programación estructurada mejora y cambia la programación en ensamblador, la programación orientado a objetos mejora y cambia a la programación estructurada. Para que se entienda mejor esta idea, por favor lea acerca la historia de la programación en el capitulo \textit{``Historia de la programación y su importancia en los videojuegos''} del anexo.(Capítulo. \ref{tes:hist})

Un objeto se puede entender de mejor manera si se plantea la manera en cómo se implementaría en lenguaje C. En C existen tipos de datos especiales llamados estructuras y uniones que sirven como un conjunto de datos primitivos (o incluso de otras uniones y estructuras). Si se necesitara asociar funciones a estas estructuras o uniones en lenguaje C, se debe crear una referencia por medio de apuntadores. Las \emph{Clases} son un tercer tipo de conjunto de datos que permiten asociar funciones además de ofrecer otras características especiales que hacen posible la POO. Las clases tienen permisos y no necesariamente hacen referencia a una función por medio de apuntadores. De esta manera vemos que una clase engloba tanto a tipos de datos como a funciones, lo cual define a un \emph{Objeto}. Un objeto es una implementación de una Clase, una instancia o referencia a la clase a partir de la fue creado

Una clase no es un objeto, sino el plan de construcción de uno, por lo tanto una clase siempre debe tener un método/función llamado \emph{constructor} y (para el caso de C++) un \emph{destructor}. Cuando se quiere crear o declarar un objeto, se llama al método constructor de éste, y cuando se deja de usar, se llama a su método destructor.

\subsection{Computación Gráfica}

En un principio el problema de hacer un videojuego era que la mayor parte del tiempo no se dedicaba al desarrollo del mismo sino en la generación de gráficos (porque rara vez un juego se basaba en interfaces no-gráficos). Hoy en día, la mayor cantidad de tiempo se emplea en el desarrollo del motor del juego. Esto es posible debido a que se generalizó una solución para la generación de gráficos que debe integrarse con los fines y requerimientos del motor del juego. ¿Pero cuál es esta solución general?

A finales de la década de los setenta, inicio la revolución 3D. Empezó con la llegada de gráficos 3D a las estaciones de trabajo\footnote{Categoría de equipo de cómputo cuyo tamaño es comparable a un PC y con la potencia de una mini o supercomputadora}, logrando con esto que ya no estuvieran relegados a \emph{Mainframes}\footnote{Equipo de Cómputo de mayor tamaño que llenaba un cuarto entero y que normalmente servían a varios usuarios a la vez}. El contraste era enorme - un \emph{Mainframe} era, en comparación, más costoso de mantener y difícil de administrar, mientras que las estaciones de trabajo podían ser dedicadas a una sola tarea, con menos recursos y sin afectar a muchos usuarios (si llegasen a fallar). Los participantes en esta revolución se convertirían luego en los representantes del cómputo de alto rendimiento: IBM, DEC, Sun microsystems, CDC, InterGraph, Evans \& Sutherland y Silicon Graphics.

A principios de la década de los ochentas se diseño PHIGS, una plataforma común para la generación de gráficos en 3D, sin embargo no era muy flexible, estaba basada en modo retenido\footnote{Esto significa que el render de la escena se queda residente en memoria} y también se basaba, ligeramente, en grafos de escena (que se explicará en el punto 2.3.3). En particular Silicon Graphics desarrolló una solución lo más sencilla y optimizada posible, dejando que los programadores se preocuparan por cómo estructurar el dibujado de la escena. Así es como surgió IrisGL o como mejor lo conocemos hoy, OpenGL. En OpenGL no había objetos, solo primitivas; se ejecutaba en modo inmediato \footnote{No se quedaba nada en memoria residente} y otorgaba mucha libertad en la forma de dibujar en la pantalla. 

Años más tarde y con una proliferación de aplicaciones y soluciones basadas en OpenGL, se estimaba que esta sería la solución dominante en la industria del software para el desarrollo de aplicaciones 3D. Hoy en día esto es solamente una verdad parcial, debido a la llegada de otra solución, por parte de Microsoft, más usada por programadores de videojuegos. El nombre de esta solución es DirectX, siendo Direct3D el producto similar a OpenGL, ofrece casi las mismas ventajas que este. Entre las desventajas de Direct3D respecto de OpenGL se encuentra la exclusividad que tiene para las plataformas de Microsoft: Windows y Xbox. OpenGL por su parte, ya sea su última versión (3.0) o la versión embebida (OpenGL ES), se encuentran en prácticamente todas las demás plataformas; desde celulares, consolas de videojuegos, PCs y Macs, hasta Clusters de Computadoras.

Ahora se puede hablar de las dos soluciones (que desde ahora haremos referencia a ellas como APIs\footnote{Application Programming Interface}), bajo los mismos términos cuando hablemos de gráficos, porque como se ha anteriormente mencionado, se basan en los mismos principios, pero con enfoques distintos. Las dos trabajan con primitivas y las dos funcionan en modo inmediato\footnote{Direct3D implementó el modo inmediato a partir de la versión 5.0 de DirectX}.

El elemento fundamental de los gráficos en 3D, es el vértice: una estructura de datos que contiene 3 números, ya sean enteros o flotantes. A partir de estos vértices se puede definir su conexión y si entre ellos se forma un plano ya que esta es la información necesaria para dibujarlo en pantalla. Generalmente están estructurados en triángulos o en cuadriláteros pero existen también planos con mas vértices. Dibujarlos en la pantalla, o el rendereo, se hace por medio de matrices de transformación particulares a dos sistemas de coordenadas - proyectado e isométrico. Desde el procesamiento de vértices hasta que se dibuja en la pantalla, pasa por una serie de estados que en conjunto se llama el \textit{Pipeline Gráfico}.

\label{ant:pipeline}
Hasta hace algunos años, este \textit{Pipeline Gráfico} estaba determinado por los arquitectos de los APIs o (de manera limitada) por quienes implementaban las librerías de OpenGL. Recientemente, con Direct3D 10 y OpenGL 3.02 (con extensiones de NVIDIA), se ha vuelto totalmente reprogramable este pipeline por medio de shaders.

Más adelante se explicará como funcionan algunos aspectos del pipeline y los \emph{shaders} (pag.~\pageref{an:shaders})

\subsubsection{Transformaciones}
Lo relevante para entender la importancia de los vértices, es la forma en como OpenGL y otros APIs 3D, han manejado sus transformaciones en el espacio: traslado, rotación y escalamiento. Resulta natural pensar que los vértices se componen por ternas en el espacio, pero en efecto se usan cuaternas para facilitar su transformación por medio de matrices (y por la multiplicación de matrices se logra facilitar su procesamiento al CPU/GPU).

\paragraph{Traslación}
Partiendo de una cuaterna arbitraria

\[A=\left(x,y,z,1\right)\]

se puede trasladar un vector en cualquier sentido por medio de la siguiente multiplicación:

\[ A* \left(
\begin{array}{cccc}
1 & 0 & 0 & 0 \\
0 & 1 & 0 & 0 \\
0 & 0 & 1 & 0 \\
tx & ty & tz & 1
\end{array}
\right)=(x+tx,y+ty,z+tz,1)\]

\paragraph{Rotación}
La rotación depende mucho de que API se este usando (Direct3D usa coordenadas de la mano izquierda mientras que OpenGL de la mano derecha). Las rotaciones se realizan respecto a un eje y en secuencia (X primero, Y segundo, Z tercero) debido a que la multiplicación entre matrices no es conmutativa. En el caso de OpenGL, las matrices de rotación son las siguientes (donde \(\phi\) es el ángulo de rotación):

Rotación sobre el eje x \[\left(
\begin{array}{cccc}
1 & 0 & 0 & 0 \\
0 & \cos{\phi} & -\sin{\phi} & 0 \\
0 & \sin{\phi} & \cos{\phi} & 0 \\
0 & 0 & 0 & 1
\end{array}
\right)\]

Rotación sobre el eje y \[\left(
\begin{array}{cccc}
\cos{\phi} & 0 & \sin{\phi} & 0 \\
0 & 1 & 0 & 0 \\
-\sin{\phi} & 0 & \cos{\phi} & 0 \\
0 & 0 & 0 & 1
\end{array}
\right)\]

Rotación sobre el eje z \[\left(
\begin{array}{cccc}
\cos{\phi} & -\sin{\phi} & 0 & 0 \\
\sin{\phi} & \cos{\phi} & 0 & 0 \\
0 & 0 & 1 & 0 \\
0 & 0 & 0 & 1
\end{array}
\right)\]

Para tener nuestra matriz final de transformación, simplemente multiplicamos cada componente:
\[matrizDeTransformacionFinal = matrizx * matriz y * matriz z \]

Finalmente esta matriz resultante la postmultiplicamos por nuestro vector.

\paragraph{Escalamiento}
Partiendo de una cuaterna arbitraria \[A=\left(x,y,z,1\right)\], se puede escalar un vector por medio de la siguiente multiplicación:

\[ A* \left(
\begin{array}{cccc}
sx & 0 & 0 & 0 \\
0 & sy & 0 & 0 \\
0 & 0 & sz & 0 \\
0 & 0 & 0 & 1
\end{array}
\right)=(x\times{sx},y\times{sy},z\times{tz},1)\]

\newpage

\subsubsection{Shaders}
\label{an:shaders}
Una tecnología que ha recobrado mucho auge en el 3D interactivo son los \emph{shaders} que descienden directamente de los \emph{shaders} del 3D fotorealístico.

Un shader, en su definición original, es un algoritmo que define el relleno de planos entre vectores o el dibujo de varios planos conformando una superficie. Puede ser tan simple como un algoritmo de iluminación plana (flat shading) hasta un algoritmo que calcule modelos de iluminación que simulan fotones y que incluye efectos visuales como agregar detalles en las texturas que simulan mayor complejidad geométrica (bump-mapping). Este proceso de control tiene su origen en los métodos de dibujo fotorealísticos (REYES, RenderMan, MentalRay) donde cada método definía su propio lenguaje de programación para estos algoritmos\footnote{Shaders fotorealísticos}. Subsecuentemente llegó a los métodos de dibujo en tiempo real y debido a la flexibilidad del hardware para el procesamiento de los algoritmos, se ha extendido al control de vértices y geometrías\footnote{Shaders en tiempo real}. En lo que sigue se explicaran los \emph{shaders} en este último contexto.\cite{openglbible}

Los \emph{shaders} de tiempo real se realizaban, en un principio, en los mainframes gráficos (los SGI Onyx, por ejemplo) por medio de la biblioteca OpenShaders de SGI que se basaba en la generación de texturas en tiempo real y su almacenamiento temporal en memoria para luego encimar varias texturas una sobre la otra (con efectos de transparencia). Este método era extremadamente ineficiente y caro, por lo que se dejaron de utilizar las tarjetas dedicadas al pipeline a favor de GPU's\footnote{Unidad de procesamiento gráfico o GPU ( acrónimo del inglés Graphics Processing Unit)} más versátiles. Ésto último dio por resultado la creación de varios lenguajes para programar \emph{shaders}, dando lugar a la actual incompatibilidad de los programas \emph{shaders} entre cada plataforma.

Como se había mencionado anteriormente, los \emph{shaders} hacen posible cambiar al Pipeline Gráfico, ya sea de Direct3D u OpenGL. El pipeline original era muy rígido, fijo en su implementación y optimizado para los limites del hardware de SGI (ver figura~\ref{fig:pipeline1}). El uso de \emph{shaders} cambia este esquema y se da mayor flexibilidad en la transformación de los vértices, las luces e incluso los fragmentos (antes de enviar todo al \emph{framebuffer}\footnote{Memoria de la pantalla o de la tarjeta de video.}). (ver figura~\ref{fig:pipeline2})

\begin{figure}[H]
	\centering
      \includegraphics[scale=0.5]{img/pipeline1.pdf}
     \caption{Pipeline Tradicional de OpenGL}
	\label{fig:pipeline1}
\end{figure}

Inicialmente para incluir código extra en el pipeline gráfico se recurría al ensamblador del GPU para incluir procesos extras, pero desde OpenGL 1.5, se ha podido programar en dos niveles: bajo (como ensamblador para gráficos) y alto (un lenguaje procedural tipo C). Ambos niveles tienen sus ventajas y desventajas, pero hoy en día, casi no se programa a bajo nivel.

En OpenGL, este lenguaje de \emph{shaders} se llama GLSL\footnote{Graphics Library Shading language}. En Direct3D se llama HLSL\footnote{High Level Shading Language}. La empresa de Hardware 3D, nVidia, nos presenta con un tercer candidato que promete unificar los dos estándares, CG\footnote{C for Graphics}. CG, para lograr unificar los estándares de shader, se construye a partir de los dos lenguajes y ofrece un lenguaje parecido al HLSL. En OpenGL se presenta como una biblioteca \emph{wrapper}, mientras que en Direct3D aparenta una extensión o modificación de su lenguaje nativo.

Al poder editar el pipeline en un lenguaje universal (CG) se pueden hacer efectos especiales en los videojuegos que antes no se podía contemplar, debido a la gran demanda de recursos y la exclusividad para una sola plataforma.


\begin{figure}[H]
	\centering
      \includegraphics[scale=0.5]{img/pipeline2.pdf}
      \caption{Pipeline con \emph{shaders} de OpenGL}
      \label{fig:pipeline2}
\end{figure}

\subsection{Grafos de Escena}
%Se había mencionado brevemente las ventajas de la programación orientado a objetos (modularidad, reuso y portabilidad), pero puede entrar aquí también una nueva paradigma de computo gráfico, semejante a lo que hizo C++ a C. A una paradigma orientado a objetos se le debe atribuir también un equivalente en gráficos: Los Grafos de Escena.

Un grafo de escena es una estructura de datos que contiene descriptores de la geometría y apariencia de un escenario virtual así como la organización espacial de la escena. Los grafos de escena almacenan información en \emph{nodos} que describen la geometría de dicha escena y otros nodos hijos que contienen descriptores que afectaran a los que jerárquicamente descienden de ellos.

Para el cómputo gráfico, los grafos de escena definieron un nuevo paradigma para organizar la información de lo que se dibuja en pantalla. 

La librería OGRE no es un grafo de escena, sino una implementación de este, para poder llevar a cabo las mismas operaciones en máquinas con menos recursos. La idea de los grafos de escena es establecer una cierta jerarquía a las geometrías y que sus transformaciones y forma de dibujarse sea lo más eficiente. Esto se logra organizando a los objetos en un árbol de $n$ niveles de profundidad y $n$ cantidad de hojas en cada nivel.

OGRE es un motor de render gráfico que utiliza las funciones de bajo nivel de manejo de memoria de forma que resulte más sencilla y portable su manipulación, permitiendo utilizar internamente la especificación de OpenGL o Direct3D a elección del programador (o dependiendo de la plataforma utilizada), aunque no es tan versátil o complejo como OpenSceneGraph, que sí es propiamente un grafo de escena.

Retomando la idea de un árbol, cada una de las hojas es lo que se dibuja en pantalla bajo diferentes contextos (principalmente dependiendo de la posición de la cámara y su campo de visión). Una de las características de los grafos de escena es que permiten eliminar del procesamiento a cualquier geometría que no este siendo visualizada por el usuario de manera eficiente (esto es, todavía existe en memoria, pero ya no se dibuja).

Los nodos que maneja OGRE, excepto el de la raiz, contienen la siguiente información acerca de los elementos que alojan:
\begin{quote}
	\begin{itemize}
\item Transformación - Tiene su propia matriz de transformación.
\item Grupo  - Puede tener $n$ número de nodos hijos.
\item Gráfico - Puede tener $n$ número de geometrías asociadas.
\end{itemize}
\end{quote}

La forma en que se organizan estos elementos es análoga a las pilas en OpenGL. Con las pilas es posible definir una asociación espacial entre varias geometrías, ya sea de manera individual o de grupo, por medio de matrices de transformación. Las geometrías, a su vez, son arreglos de vértices asociados a un arreglo de índices. Los índices describen, en OpenGL, la manera de dibujar las caras que posteriormente generará una figura en tres dimensiones. El árbol de grafos puede verse como la evolución lógica de esta estructura de la pila, ya que brinda las mismas facilidades para crear y manipular geometrías además de presentar una forma eficiente para el dibujo de la escena.

A continuación se ejemplifica un sistema solar en un API 3D genérico (usando pilas):

\begin{verbatim}
/*Iniciar la pila*/
PushMatrix()
/*Camara/vista del usuario*/
Rotar(Rot\_Mouse)
/*Rotamos todo lo que esta dentro según las coordenadas del mouse*/
Dibuja\_Sol()
/*Función que crea una esfera que representa al Sol, con una textura amarilla*/
PushMatrix()
/*Creamos otra Matriz de Transformación que esta asociada al Sol
y gira cuando hacemos girar la cámara con el mouse*/
Rotar(x)
/*Rotamos x grados cada cuadro*/
Desplazar(10)
/*Desplazamos 10 unidades para dibujar al planeta Mercurio*/
escalar(.25)
/*Escalamos a un cuarto del tamaño de la tierra*/
Dibuja\_planeta(mercurio, rojo, 0)
/*Pasamos los parámetros para dibujar a Mercurio*/
PopMatrix()
/*Cerramos esta matriz pero aún estamos bajo la influencia de la
matriz anterior*/
...
... /*Dibujamos a los otros 7 planetas*/
...
PopMatrix()
/*Hasta aquí ya se ha finalizado el sistema solar, entonces se sale de la
influencia de la última matriz*/
\end{verbatim}

A continuación se presenta el mismo modelo pero implementado con grafos de escena.

\begin{figure}[H]
\centering
\includegraphics[scale=0.3]{img/scenegraph.pdf}
\caption[scenegraph]{}
\label{fig:scenegraph}
\end{figure}
La diferencia aquí es que cada traslación, rotación y escalamiento son métodos o funciones de los nodos NMT. Cada nodo también tiene un método para insertar un nodo hijo. Los nodos hijos, al igual que el nodo del Sol, tienen un método para asociarse a una geometría. Los grafos de escena engloban en objetos todas las operaciones que tradicionalmente se usan en un motor gráfico.

Dentro de las ventajas de emplear grafos de escena es la manera en como se \textit{podan}\footnote{Se conoce como \emph{podar} al proceso de eliminación de un subárbol} datos. Por un lado se asocian los objetos en el árbol por cuestiones de mecánica\footnote{Al crear un objeto, sus partes se ligan jerárquicamente, como sucedería al modelar un brazo, por lo que, los objetos dependen del movimiento de otro objeto, etc.}. Por otra parte, se asocian dependiendo del punto de vista del usuario, para poderse llevar a cabo un podado eficiente. Según el campo de visión que tiene el usuario, es mas fácil de eliminar las raíces de varios nodos que no se observen, en vez de ir eliminando a cada nodo.

En lo anterior es en lo que se basa la filosofía de los grafos de escena y normalmente su optimización es lo que consume más tiempo del desarrollo de una escena.

\subsection{Inteligencia Artificial}

No es posible definir a la inteligencia de forma única pues incluye procesos psicológicos que es complicado describir. La inteligencia humana se relaciona con la capacidad de razonar sobre un problema, la palabra inteligencia es de origen latino, \emph{intelligent\~\i a}, término compuesto de \emph{intus} ``entre'' y \emph{legere} ``escoge'', por lo que, etimológicamente, inteligente es quien sabe escoger, psicológicamente inteligencia es una capacidad cognitiva de aprendizaje y relación. La cognición se refiere a la facultad de los seres de procesar información a partir de la percepción.

La percepción esta relacionada al concepto de conocimiento. En el sentido filosófico se define como un modelo de la realidad en la mente. En el área de las ciencias técnicas y entre ellas la ingeniería, se puede definir como un conjunto de datos e información destinados para resolver un problema. El concepto de conocimiento nos lleva entonces al aprendizaje que se trata de un término asociado al ser humano y se refiere al proceso de adquirir conocimiento.

\begin{figure}[H]
\centering
\includegraphics[scale=.8]{img/Conocimiento.pdf}
\caption[esquema-conocimiento]{Esquema sobre el conocimiento desde el punto de vista de las ciencias de la información, como se genera y como se aplica\cite{conocimiento}.}
\label{fig:conocimiento}
\end{figure}

La idea de implementar Inteligencia Artificial o \emph{IA} \footnote{Del las siglas en inglés \emph{AI}, ``Artificial Intelligence''} surge de hacer que el usuario o jugador pueda competir contra la computadora. En los primeros videojuegos no se tenía esta interacción debido a que se trataba de dos jugadores sin intervención de la computadora como contrincante.

Con la evolución de los videojuegos y de los recursos computacionales de los que se disponía, gradualmente se empezaron a utilizar técnicas de IA en videojuegos de un solo jugador. Un ejemplo de esto es \emph{Pong}, en el que era posible jugar contra la computadora que usaba la información de posición de la pelota para realizar su movimiento.

Una técnica muy usada por estos primeros videojuegos era crear la ilusión de IA al implementar algoritmos aleatorios para alcanzar el objetivo deseado, el resultado era aparentar \emph{intención} por parte de la computadora por obtener la victoria durante el juego, un ejemplo de esto lo podemos ver con los fantasmas enemigos en el videojuego \emph{Pac-Man}, donde se puede percibir que los fantasmas buscan al personaje principal.

Un aspecto fundamental al implementar IA en los videojuegos, independientemente de la tecnología que se use, es diseñarla para maximizar la experiencia de interacción del jugador y brindar un nivel apropiado de \emph{reto}; la computadora no siempre tiene que ganar o perder.

Otro aspecto importante es que el comportamiento de los personajes controlados por la computadora sea difícil de distinguir de un jugador humano; la \emph{credibilidad} en el comportamiento de los jugadores por lo general es el objetivo principal en la IA de un videojuego, más importante incluso que simular ambientes reales.

A continuación se presentan los algoritmos utilizados comúnmente en la implementación de Inteligencia Artificial para los videojuegos actuales.

\subsubsection{Búsqueda de Rutas con A*}

El uso de algoritmos de búsqueda en videojuegos está relacionado con obtener la ruta más corta, si es que esta existe, entre dos puntos. De forma general, una búsqueda intenta solucionar problemas espaciales más abstractos, por ejemplo usando grafos de puntos conectados, entre los cuales existen distancia de unos a otros, donde un punto representa la solución deseada y otro el inicio de la búsqueda. A* es una de las técnicas más comunes en la mayoría de los videojuegos. El algoritmo A* (y muchas de sus variantes) utiliza heurística para conducir la búsqueda hacia el destino objetivo, resultando de ello un mejor rendimiento de otros algoritmos como los de búsqueda por profundidad (DFS\footnote{Del término en inglés, \emph{Depth First Search}. Este algoritmo recorre todo el árbol de búsqueda o grafo de forma ordenada, pero no uniforme.}) o por anchura (BFS\footnote{Del término en inglés, \emph{Breadth First Search}. Algoritmo de búsqueda sin información, que expande y examina todos los nodos de un árbol sistemáticamente para buscar una solución}).

\subsubsection{Minimax}

Minimax fue uno de los primeros algoritmos de Inteligencia Artificial que se usaron específicamente para el desarrollo de videojuegos, usado en juegos como damas o ajedrez por muchas décadas. Funciona haciendo que el personaje no jugador evalúe todos los posibles movimientos y seleccione el de mayor puntaje de acuerdo con con alguna métrica específica.

\subsubsection{Máquinas de Estado Finito}

Una máquina de estado finito\footnote{Del término en inglés FSM, Finite State Machines} consiste en varios estados conectados entre sí, con varias posibles transiciones entre los estados y funciones que causan la transición entre éstos. Son comúnmente usados dentro de un videojuego en personajes que cambian entre comportamientos predefinidos, por ejemplo, con guardias patrullando que escuchan algún sonido cercano y dejan su recorrido para investigar y posteriormente regresan a patrullar cuando se lanza una función de que ha pasado un tiempo definido.

Las máquinas de estado finito permiten definir lógica en un videojuego, pero a medida que esta lógica se complica en el desarrollo del juego, se vuelve más complicado controlar el comportamiento de los personajes debido a que esta técnica involucra programar muchos tipos de comportamiento. Si se pretende reusar el código que los generó (que es el objetivo común al utilizar esta técnica), las máquinas de estado deben ser sensibles al contexto, dependiendo de los objetivos del personaje en un momento dado y adaptándose al estado actual del personaje (por ejemplo, su nivel de energía), lo que vuelve complicada la lógica que debe producirlos.


